cargo-deny: allow the MPL-2.0 and OpenSSL licenses#6136
Conversation
These are required in order to merge #5929.
pchickey
requested review from
a team,
elliottt,
fitzgen and
tschneidereit
and removed request for
a team and
elliottt
| "ISC", | ||
| "MIT", | ||
| "MPL-2.0", | ||
| "OpenSSL", |
There was a problem hiding this comment.
Why is OpenSSL license still necessary if #5929 (comment) has switched to rustls?
There was a problem hiding this comment.
Yes, because the ring crate includes the OpenSSL license in its LICENSE file.
|
I am strongly in favor of adding MPL-2.0, but I needed to review OpenSSL. We may need to add an open source software acknowledgements section to the wasmtime docs to include "This product includes software developed by the OpenSSL Project |
tschneidereit
left a comment
tschneidereit
left a comment
There was a problem hiding this comment.
As discussed, I agree with this change.
@ricochet, Pat and I talked about this and agreed that these licenses don't change anything foundational: we already have a few licenses that require attribution even for binary distributions, and need to figure out an approach to dealing with them. I have some thoughts on the topic, but given that these licenses don't fundamentally change the picture, I think all this doesn't need to hold up landing this change.
fitzgen
left a comment
fitzgen
left a comment
There was a problem hiding this comment.
I've always been partial to MPL-2.0 :)
|
I added 1 more commit that clarifies the license for |
`wasmtime` v39+ has an MPL-2.0 dependencies, so we avoid upgrading for now. `wasmtime` also does not view the MPL-2.0 license as conflicting with their Apache-2.0 license (somewhat contrary to our current understanding), so we do not expect this to change in the near future: bytecodealliance/wasmtime#6136
5 participants
These are required in order to merge #5929.
I discussed this change with Till: we believe that these licenses are compatible with Wasmtime's license and don't add any fundamentally new requirements to the existing allow-list.
In an ideal world, I could imagine making an RFC or asking the Bytecode Alliance board weigh in on this decision, but we don't have any process or guidance for how to go about changing this list, and we don't expect this change to be controversial in any way. So, I've asked all of the BA TSC members (@fitzgen @tschneidereit @ricochet) to please approve this PR before I merge it.